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Abstract 


This specification defines a new SIP header field, Feature-Caps. The 
Feature-Caps header field conveys feature-capability indicators that 
are used to indicate support of features and capabilities for SIP 
entities that are not represented by the Uniform Resource Identifier 
(URI) of the Contact header field. 


SIP entities that are represented by the URI of the SIP Contact 
header field can convey media feature tags in the Contact header 
field to indicate support of features and capabilities. 


This specification also defines feature-capability indicators and 
creates a new IANA registry, "Proxy-Feature Feature-Capability 
Indicator Trees", for registering feature-capability indicators. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http: //www.rfc-editor.org/info/rfc6809. 
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1. Introduction 


The Session Initiation Protocol (SIP) [RFC3261] extension for 
indicating User Agent (UA) capabilities, defined in RFC 3840 
[RFC3840], provides a mechanism that allows a SIP message to convey 
information relating to the originator’s features and capabilities, 
using the Contact header field. 


This specification defines a new SIP header field, Feature-Caps. The 
Feature-Caps header field conveys feature-capability indicators that 
are used to indicate support of features and capabilities for SIP 
entities that are not represented by the Uniform Resource Identifier 
(URI) of the Contact header field. Such cases are: 


o The SIP entity acts as a SIP proxy. 

o The SIP entity acts as a SIP registrar. 

o The SIP entity acts as a Back-to-Back User Agent (B2BUA) 
[RFC3261], where the Contact header field URI represents another 
SIP entity. 

SIP entities that are represented by the URI of the SIP Contact 


header field can convey media feature tags in the Contact header 
field to indicate support of features and capabilities. 
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Unlike media feature tags, feature-capability indicators are intended 
to only be used with SIP. 


This specification also defines feature-capability indicators and 
creates a new IANA registry, "Proxy-Feature Feature-Capability 
Indicator Trees", for registering feature-capability indicators. 


2. Conventions 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in BCP 14, RFC 2119 
[RFC2119]. 


3. Definitions 


Downstream SIP entity: SIP entity in the direction towards which a 
SIP request is sent. 


Upstream SIP entity: SIP entity in the direction from which a SIP 
request is received. 


4. Feature-Caps Header Field 
4.1. Introduction 


The Feature-Caps header field is used by SIP entities to convey 
support of features and capabilities, by setting feature-capability 
indicators. A feature-capability indicator conveyed in a 
Feature-Caps header field indicates that a SIP entity in the SIP 
message signaling path supports the associated feature and 
capability. 


4.2. User Agent and Proxy Behavior 
4.2.1. General 


If the URI in a Contact header field of a request or response 
represents a SIP entity, the entity MUST NOT indicate supported 
features and capabilities using a Feature-Caps header field within 
that request or response. 


when a SIP entity receives a SIP request, or response, that contains 
one or more Feature-Caps header fields, the feature-capability 

indicators in the header field inform the entity about the features 
and capabilities supported by entities in the SIP message signaling 
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path. The procedure by which features and capabilities are invoked 
are outside the scope of this specification and MUST be described by 
individual feature-capability indicator specifications. 


A Feature-Caps header field value cannot convey the address of the 
SIP entity that inserted the Feature-Caps header field. If 
additional data about a supported feature needs to be conveyed, such 
as the address of the SIP entity that indicated support of the 
feature, then the feature definition needs to define a way to convey 
that information as a value of the associated feature-capability 
indicator. 


when a SIP entity adds a Feature-Caps header field to a SIP message, 
it MUST place the header field before any existing Feature-Caps 
header field in the message to be forwarded, so that the added header 
field becomes the top-most one. Then, when another SIP entity 
receives a SIP request or the response, the SIP feature-capability 
indicators in the top-most Feature-Caps header field will represent 
the supported features and capabilities "closest", from a SIP 
signaling point of view, to the entity. 


Based on features and policies, a SIP entity MAY remove a 
Feature-Caps header field from a SIP message. Also, a SIP entity MAY 
remove a feature-capability indicator from a Feature-Caps header 
field within a SIP message. A SIP entity SHOULD NOT re-order the 
Feature-Caps header fields within a SIP message. 


For a given fc-value, as defined in Section 6.2.1, the order in which 
feature-capability indicators are listed has no significance. For 
example, "foo;bar" and "bar; foo" have the same meaning (i.e., that 
the SIP entity that inserted the feature-capability indicator 
supports the features and capabilities associated with the "foo" and 
"bar" feature-capability indicators). 


4.2.2. B2BUA Behavior 


The procedures in this section apply to User Agents (UAs) [RFC3261] 
that are part of B2BUAs that are referenced in the message by a 
Record-Route header field rather than by the URI of the Contact 
header field. 


When such a UA sends a SIP request, if the UA wants to indicate 
support of features and capabilities towards its downstream SIP 
entities, it inserts a Feature-Caps header field in the request, 
containing one or more feature-capability indicators associated with 
the supported features and capabilities, before it forwards the 
request. 
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If the SIP request is triggered by another SIP request that the B2BUA 
has received, the UA MAY forward received Feature-Caps header fields 
by copying them to the outgoing SIP request, similar to a SIP proxy, 
before it inserts its own Feature-Caps header field in the SIP 
request. 


when such a UA receives a SIP response, if the UA wants to indicate 
support of features and capabilities towards its upstream SIP 
entities, it inserts a Feature-Caps header field in the response, 
containing one or more feature-capability indicators associated with 
the supported features and capabilities, before it forwards the 
response. 


If the SIP response is triggered by another SIP response that the 
B2BUA has received, the UA MAY forward received Feature-Caps header 
fields by copying them to the outgoing SIP response, similar to a SIP 
proxy, before it inserts its own Feature-Caps header field in the SIP 
response. 


4.2.3. Registrar Behavior 


If a SIP registrar wants to indicate support of features and 
capabilities towards its upstream SIP entities, it inserts a 
Feature-Caps header field, containing one or more feature-capability 
indicators associated with the supported features and capabilities, 
in a REGISTER response. 


4.2.4. Proxy Behavior 


When a SIP proxy receives a SIP request, if the proxy wants to 
indicate support of features and capabilities towards its downstream 
SIP entities, it inserts a Feature-Caps header field in the request, 
containing one or more SIP feature-capability indicators associated 
with the supported features and capabilities, before it forwards the 
request. 


When a proxy receives a SIP response, if the proxy wants to indicate 
support of features and capabilities towards its upstream SIP 
entities, it inserts a Feature-Caps header field in the response, 
containing one or more SIP feature-capability indicators associated 
with the supported features and capabilities, before it forwards the 
response. 
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4.3. SIP Message Type and Response Code Semantics 
4.3.1. General 


This section describes the general usage and semantics of the 
Feature-Caps header field for different SIP message types and 
response codes. 


Section 6.2.1 defines the Feature-Caps header field ABNF. 
4.3.2. SIP Dialog 


The Feature-Caps header field can be used within an initial SIP 
request for a dialog, within a target refresh SIP request, and within 
any 18x or 2xx response associated with such requests. 


If a feature-capability indicator is inserted in a Feature-Caps 
header field of an initial request for a dialog, or within a response 
of such a request, it indicates to the receivers of the request (or 
response) that the feature associated with the feature-capability 
indicator is supported for the duration of the dialog, until a target 
refresh request is sent for the dialog, or until the dialog is 
terminated. 


Unless a feature-capability indicator is inserted in a Feature-Caps 
header field of a target refresh request, or within a response of 
such a request, it indicates to the receivers of the request (or 
response) that the feature is no longer supported for the dialog. 


For a given dialog, a SIP entity MUST insert the same feature- 
capability indicators in all 18x and 2xx responses associated with a 
given transaction. 


As it cannot be guaranteed that 2xx responses associated with SIP 
SUBSCRIBE requests will reach the User Agent Client (UAC) [RFC3261], 
due to forking of the request, entities need to indicate supported 
features and capabilities in the SIP NOTIFY request that will be sent 
for each of the created subscription dialogs. 


4.3.3. SIP Registration (REGISTER) 
The Feature-Caps header field can be used within a SIP REGISTER 
request and within the 200 (OK) response associated with such a 
request. 
If a feature-capability indicator is conveyed in a Feature-Caps 


header field of a REGISTER request, or within an associated response, 
it indicates to the receivers of the message that the feature 
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associated with the feature-capability indicator is supported for the 
registration, until the registration of the contact that was 
explicitly conveyed in the REGISTER request expires, or until the 
registered contact is explicitly refreshed and the refresh REGISTER 
request does not contain the feature-capability indicator associated 
with the feature. 


while a REGISTER response can contain contacts that have been 
registered as part of other registration transactions, support of any 
indicated feature only applies to requests sent to the contact (s) 
that were explicitly conveyed in the associated REGISTER request. 


This specification does not define any semantics for usage of the 
Feature-Caps header field in pure registration binding fetching 
messages (see Section 10.2.3 of RFC 3261), where the REGISTER request 
does not contain a Contact header field. Unless such semantics are 
defined in a future extension, fetching messages will not have any 
impact on previously indicated support of features and capabilities, 
and SIP entities MUST NOT insert a Feature-Caps header field in such 
messages. 


If SIP outbound [RFC5626] is used, the rules above apply. However, 
supported features and capabilities only apply for the registration 
flow on which support has been explicitly indicated. 


4.3.4. SIP Standalone Transactions 


The Feature-Caps header field can be used within a standalone SIP 
request and within any 2xx response associated with such a request. 


If a feature-capability indicator is inserted in a Feature-Caps 
header field of a standalone request, or within a response of such a 
request, it indicates to the receivers of the request (or response) 
that the feature associated with the feature-capability indicator is 
supported for the duration of the standalone transaction. 


5. Feature-Capability Indicators 

5.1. Introduction 
Feature-capability indicators are used by SIP entities not 
represented by the URI of the Contact header field to indicate 
support of features and capabilities, where media feature tags cannot 
be used to indicate such support. 
A value, or a list of values, that provides additional information 


about the supported feature or capability can be associated with a 
feature-capability indicator. 
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5.2. Registration Trees 
5.2.1. General 


The following subsections define registration trees, distinguished 

by the use of faceted names (e.g., names of the form 
"tree.feature-name"). The registration trees are defined in the IANA 
"Proxy-Feature Feature-Capability Indicator Trees" registry. 


The trees defined herein are similar to the global tree and SIP tree 
defined for media feature tags, in RFCs 2506 [RFC2506] and 3840 
[RFC3840]. Other registration trees are outside the scope of this 
specification. 


In contrast to RFCs 2506 and 3840, this specification only defines a 
global tree and a SIP tree, as they are the only trees defined in 
those RFCs that have been used for defining SIP-specific media 
feature tags. 


when a feature-capability indicator is registered in any registration 
tree, no leading "+" is used in the registration. 


5.2.2. Global Tree 


The global feature-capability indicator tree is similar to the media 
feature tag global tree defined in RFC 2506 [RFC2506]. 


A feature-capability indicator in the global tree will be 
distinguished by the leading facet "g.". An organization can propose 
either a designation indicative of the feature (e.g., "g.blinktags") 
or a faceted designation including the organization name (e.g., 
"g.organization.blinktags"). 


5.2.3. SIP Tree 


The SIP feature-capability indicator tree is similar to the media 
feature tag SIP tree defined in RFC 3840. 


A feature-capability indicator in the SIP tree will be distinguished 
by the leading facet "sip.". 
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5.3. Feature-Capability Indicator Specification Requirements 
5.3.1. General 


A feature-capability indicator specification MUST address the issues 
defined in the following subsections or document why an issue is not 
applicable for the specific feature-capability indicator. A 
reference to the specification MUST be provided when the feature- 
capability indicator is registered with IANA (see Section 8). 


It is bad practice for feature-capability indicator specifications to 
repeat procedures (e.g., general procedures on the usage of the 
Feature-Caps header field and feature-capability indicators) defined 
in this specification, unless needed for clarification or emphasis 
purposes. A feature-capability indicator specification MUST NOT 
modify the Feature-Caps header field rules and semantics defined in 
Section 4. 


A feature-capability indicator specification MUST NOT weaken any 
behavior designated with "SHOULD" or "MUST" in this specification. 
However, a specification MAY strengthen "SHOULD", "MAY", or 
"RECOMMENDED" requirements to "MUST" strength if features and 
capabilities associated with the feature-capability indicator 
require it. 


5.3.2. Overall Description 


The feature-capability indicator specification MUST contain an 
overall description of the feature-capability indicator: how it is 
used to indicate support of a feature, a description of the feature 
associated with the feature-capability indicator, a description of 
any additional information (conveyed using one or more feature- 
capability indicator values) that can be conveyed together with the 
feature-capability indicator, and a description of how the associated 
feature MAY be exercised/invoked. 


5.3.3. Feature-Capability Indicator Values 


A feature-capability indicator can have an associated value, or a 

list of values. The feature-capability indicator specification MUST 
define the syntax and semantics of any value defined for the feature- 
capability indicator, including possible restrictions related to the 


usage of a specific value. The feature-capability indicator 
specification MUST define the value(s) in accordance with the ABNF 
defined in Section 6.3.2. The feature-capability indicator 


specification MUST define whether the feature-capability indicator 
has a default value. 
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If no values are defined for the feature-capability indicator, it 
MUST be indicated in the feature-capability indicator specification. 


A feature-capability indicator value is only applicable for the 
feature-capability indicator for which it has been defined. For 
other feature-capability indicators, the value has to be defined 
explicitly, even if the semantics are identical. 


It is strongly RECOMMENDED to not re-use a value that already has 
been defined for another feature-capability indicator, unless the 
semantics of the values are the same. 


5.3.4. Usage Restrictions 
If there are restrictions on how SIP entities can insert a feature- 
capability indicator, the feature-capability indicator specification 
MUST document such restrictions. 
There might be restrictions related to whether or not entities 
o are allowed to insert a feature-capability indicator in 
registration-related messages, standalone transaction messages, or 


dialog-related messages, 


o are allowed to insert a feature-capability indicator in requests 
or responses, 


o also need to support other features and capabilities in order to 
insert a feature-capability indicator, and 


o are allowed to indicate support of a feature in conjunction with 
another feature. 


5.3.5. Interoperability Considerations 
The feature-capability indicator specification MUST document any 
specific interoperability considerations that apply to the feature- 
capability indicator. 
Interoperability considerations can, e.g., include procedures related 
to cases where an expected feature-capability indicator is not 
present or where it contains an unexpected value. 

5.3.6. Security Considerations 
The feature-capability indicator specification MUST document any 


specific security considerations that apply to the feature-capability 
indicator. 
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5.3.7. Examples 


It is recommended that the feature-capability indicator specification 
provide demonstrative message flow diagrams, paired with complete 
messages and message descriptions. 


Note that example message flows are by definition informative and do 
not replace normative text. 


5.3.8. Other Information 
If there is additional information about the feature-capability 


indicator, it is recommended to describe such information. It can 
include, for example, names of related feature-capability indicators. 


6. Syntax 

6.1. General 
This section defines the ABNF for the Feature-Caps header field and 
for the feature-capability indicators. The ABNF defined in this 
specification is conformant to RFC 5234 [RFC5234]. 

6.2. Syntax: Feature-Caps Header Field 


6.2.1. ABNF 


The ABNF for the Feature-Caps header fields is: 


Feature-Caps = "Feature-Caps" HCOLON fc-value 
* (COMMA fc-value) 
fc-value = "*" * (SEMI feature-cap) 


NOTE: The "*" value is present in order to follow the guidelines for 
syntax in RFC 4485 [RFC4485] and to maintain a consistent format with 
RFCs 3840 [RFC3840] and 3841 [RFC3841]. 


6.3. Syntax: Feature-Capability Indicator 

6.3.1. General 
In a feature-capability indicator name (ABNF: fcap-name), dots can be 
used to implement a feature-capability indicator tree hierarchy 


(e.g., tree.feature.subfeature). The description of usage of such a 
tree hierarchy must be described when registered. 
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6.3.2. ABNF 


The ABNF for the feature-capability indicator is: 


feature-cap = "+" fcap-name [EQUAL LDQUOT (fcap-value-list 
/ fcap-string-value ) RDQUOT] 

fcap-name = ftag-name 

fcap-value-list = tag-value-list 

fcap-string-value = string-value 


;; ftag-name, tag-value-list, string-value defined in RFC 3840 


NOTE: In comparison with media feature tags, the "+" sign in front of 
the feature-capability indicator name is mandatory. 


7. IANA Considerations 
7.1. Registration of the Feature-Caps Header Field 


This specification registers a new SIP header field, Feature-Caps, 
according to the process defined in RFC 3261 [RFC3261]. 


The following is the registration for Feature-Caps in the "Header 
Fields" registry: 


RFC Number: RFC 6809 
Header Field Name: Feature-Caps 
7.2. Registration of the Feature-Caps Header Field Parameter 
This specification adds the Feature-Caps header field to the IANA 


"Header Field Parameters and Parameter Values" registry, according to 
the process described in RFC 3968 [RFC3968]. 


Predefined 
Header Field Parameter Name Values Reference 
Feature-Caps +<fcap-name> * No [RFC6809] 


* <fcap-name> denotes parameter names conforming to the 
syntax <fcap-name> defined in RFC 6809. Valid 
feature-capability indicators are registered in the 
Proxy-Feature Feature-Capability Indicator Trees registry. 
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7.3. Proxy-Feature Feature-Capability Indicator Trees 
7.3.1. Introduction 


This specification creates a new sub-registry to the IANA "Session 
Initiation Protocol (SIP) Parameters" registry, according to the 
process defined in RFC 5226. The name of the sub-registry is 
"Proxy-Feature Feature-Capability Indicator Trees". 


Feature-capability indicators are categorized by the "leading facet" 
of their name. The leading facet is a prefix of the name consisting 
of all characters up to and including the first ".". Feature- 
capability indicator names that contain no "." characters are 
considered to have an empty ("") leading facet. 


The "Proxy-Feature Feature-Capability Indicator Trees" registry 
contains sub-registries for subsets (called 'trees') of feature- 
capability indicators sharing the same leading facet. Each feature- 
capability indicator is registered within the tree that matches its 
leading facet. If no tree matches its leading facet, then the 
feature-capability indicator cannot be registered. 


New feature-capability indicator sub-registries (trees) can be 
registered. The registration must meet the "Standards Action" 
policies defined in RFC 5226 [RFC5226]. A new name, unique leading 
facet, and registration policies (as defined in RFC 5226) for 
feature-capability indicators within this tree need to be provided. 


This document defines the first two feature-capability indicator 
trees ("g." and "sip."). It does not define a tree for the empty 
leading facet. 


7.3.2. Global Feature-Capability Indicator Registration Tree 


This specification creates a new feature-capability indicator tree in 
the IANA "Proxy-Feature Feature-Capability Indicator Trees" registry. 
The name of the tree is "Global Feature-Capability Indicator 
Registration Tree", and its leading facet is "g.". It is used for 
the registration of feature-capability indicators. 


When a feature-capability indicator is registered in the global tree, 
it needs to meet the "Specification Required" policies defined in 

RFC 5226. A designated area expert will review the proposed feature- 
capability indicator and consult with members of related mailing 
lists. The information required in the registration is defined in 
Section 5.3 of this document. 
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Note that all feature-capability indicators registered in the global 
tree will have names with a leading facet "g.". No leading "+" is 
used in the registrations in any of the feature-capability indicator 
registration trees. 


The format of the global tree is as described below: 


Name Description Reference 


Name - contains the Feature-Capability Indicator Name, provided in 
the registration feature-capability indication registration template. 


Description - provided in the registration feature-capability 
indication registration template. 


Reference - contains the Feature-Capability Indicator specification 
reference provided in the registration feature-capability indication 
registration template. 


No initial values are registered in the global tree. 


7.3.3. SIP Feature-Capability Indicator Registration Tree 


This specification creates a new feature-capability indicator tree in 
the IANA "Proxy-Feature Feature-Capability Indicator Trees" registry. 
The name of the tree is "SIP Feature-Capability Indicator 
Registration Tree", and its leading facet is "sip.". It is used for 
the registration of feature-capability indicators. 


When a feature-capability indicator is registered in the SIP tree, it 
needs to meet the "IETF Review" policies defined in RFC 5226. The 
information required in the registration is defined in Section 5.3 of 
this document. 


Note that all feature-capability indicators registered in the SIP 
tree will have names with a leading facet "sip.". No leading "+" is 
used in the registrations in any of the feature-capability indicator 
registration trees. 
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The format of the SIP tree is as described below: 


Name Description Reference 


Name - contains the Feature-Capability Indicator Name, provided in 
the registration feature-capability indication registration template. 


Description - provided in the registration feature-capability 
indication registration template. 


Reference - contains the Feature-Capability Indicator specification 
reference provided in the registration feature-capability indication 
registration template. 

No initial values are registered in the SIP tree. 


8. Feature-Capability Indicator Registration Template 


Registration requests for the global tree are submitted by email to 
jana@iana.org. 


Registration requests for the SIP tree requires submitting an 
Internet-Draft to the IESG. 


| Instructions are preceded by alae All fields are mandatory. 
Feature-capability indicator name: 

Description: 

| The description should be no longer than 4 lines. More 

| detailed information can be provided in the feature 

| capability indicator specification. 


Feature-capability indicator specification reference: 


| The referenced specification must contain the information 
| listed in Section 5.3 of RFC 6809. 


Contact: 


| Name(s) & email address(es) of person(s) to 
| contact for further information. 
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9: 


10. 


Security Considerations 


The security issues for feature-capability indicators are similar to 
the ones defined in RFC 3840 for media feature tags. Media feature 
tags can reveal information about end users and end-user equipment, 
which can be used for industrial espionage. The knowledge about end- 
user equipment capabilities can also be used to influence application 
behavior. As feature-capability indicators are not intended to 
convey capability information of end-user devices, such end-user 
security aspects of RFC 3840 do not apply to feature-capability 
indicators. 


In addition, the security issue discussed in RFC 3840 regarding an 
attacker using the SIP caller preferences extension [RFC3841] in 
order to affect routing decisions does not apply, as the mechanism is 
not defined to be used with feature-capability indicators. 


Feature-capability indicators can, however, provide capability and 
characteristics information about the SIP entity, some of which might 
be sensitive. Malicious elements viewing the indicators may be able 
to discern application deployment details or identify elements with 
exploitable feature implementation weaknesses. The Feature-Caps 
header field does not convey address information about SIP entities. 
However, individual feature-capability indicators might provide 
address information as feature-capability indicator values. 
Therefore, if the feature-capability indicators provide information 
that requires data integrity or origin authentication, mechanisms for 
providing those MUST be provided. If confidentiality is required, 
then the specification MUST call for the use of Transport Layer 
Security (TLS) [RFC5246] at all hops. Since there are no 
satisfactory middle-to-end or middle-to-middle SIP confidentiality 
mechanisms, TLS is as good as it gets, and specifications SHOULD NOT 
define feature-capability indicators that need confidentiality that 
is better than the hop-by-hop confidentiality provided by TLS. 
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